There is an ongoing integration trend between switched circuit networks (SCN) and internet protocol (IP) networks that, using the effective way to transport user data provided by IP networks, intends to get a less restrictive and network independent way of providing and deploying telecommunication services. The term SCN is used in this invention to refer to a network that carries traffic (normally, telephony traffic) within channeled bearers of predefined sizes. Examples of SCN include public switched telephone networks (PSTN), integrated services digital networks (ISDN) or public land mobile networks (PLMNs), such as a global system for mobile communications (GSM) network. The term IP network is used in this invention to refer to a network that carries traffic (normally, data traffic) within data packets.
A goal in such integration trend is to grant interoperation between end points (signaling end points or voice/multimedia terminal devices) allocated in SCN and in IP networks. Another goal in such integration trend is to allow allocation of nodes/functions, traditionally located in the SCN, into the IP network; thus allowing telecommunication operators to expand their networks and to speed up the deployment of new or existing services. An example could be the provision of a GSM node, such as a home location register node, in an IP network.
In this context, the transport of traditional SCN signaling messages over IP networks has been viewed as one of the main areas of concern and has been addressed by the signaling transport (SIGTRAN) working group of the internet engineering taskforce (IETF). The SIGTRAN working group defines an architecture and related protocols to support transport of SCN signaling (or SCN signaling messages) over IP networks in order to ensure a smooth and transparent interworking between telecommunication nodes regardless whether the nodes are located in the SCN or in the IP network. Examples of traditional SCN signaling protocols suitable to be transported over IP networks are: Q.931; signaling system number 7 (SS7) message transfer part (MTP); MTP layer-3 (MTP3) user part protocols or signaling connection control part (SCCP); user protocols, like mobile application part (MAP) over transaction capabilities application part (TCAP) etc.
In this scenario, two kinds of nodes were identified by SIGTRAN. Nodes performing functions relating to signaling conversion, named signaling gateways (SGs), intended to provide an interworking between nodes located in SCNs and nodes located in IP networks. The other kind of nodes performing functions related to signaling applications located in the IP network (IP-located nodes), named application servers (ASs). Hereinafter, throughout this document, the terms SG and AS will be used to refer to the logical entity that performs, respectively, an SG function and an AS function, regardless of whether such functions are distributed over one or more hosts of the IP network and also in order to refer to the physical entity (physical machine or physical node) that, respectively, implements or contains a SG function or an AS function.
The internet standard defining the general architecture for SIGTRAN (specified in the document RFC2719) specifies a set of three elements that would have to be implemented by any node involved in the transport of SCN signaling over IP networks (SG and AS), and that will have to be performed by the processes that implement the corresponding functionalities (a process which implements the functionality of a signaling gateway is also referred to as signaling gateway process, and a process which implements the functionality of an application server is referred to as an application server process). These elements are intended to interact with each other in a layered way within the same node's serving process, and each of them is intended to communicate with its respective peer or peer element in the interworking nodes serving process by using the services provided by the adjacent lower element in its node. These elements are: the SCN adaptation module, the common signaling transport and the standard IP transport. The SCN adaptation module is intended to be specific for the type of SCN protocol to be transported. The common signaling transport and the standard IP transport are intended to be common regardless of the SCN protocol to be transported.
For this extent, SIGTRAN working group has developed a set of internet standards that define: a set of user adaptation layers (UA) (one per type of SCN protocol to be transported), that implements the aforementioned SCN adaptation module; and a transport protocol, the stream control transmission protocol SCTP (defined in RFC2960) to be used over IP, that implements the aforementioned common signal transport, and that is able to run directly over IP. Regarding more specifically user adaptation layers (UA), SIGTRAN is defining, among others, four protocols: MTP3-user adaptation layer (M3UA), MTP2-user adaptation layer (M2UA), ISDNQ.921-user adaptation layer (IUA), and SCCP-user adaptation layer (SUA).
An application server (AS) in the IP network can be in one of the following states. The application server can be available, e.g., for a requesting peer, or unavailable, or congested. The status of an application server might also change, for example from available to unavailable or vice versa.
An application server in the IP network is identifiable by a routing key. A routing key can for example comprise a point code (PC) and a subsystem number (SSN) assigned to the application server as well as other criteria assigned to the application server. A routing key is for example specified in message fields of messages exchanged by use of the aforementioned protocols. A routing key is therefore not only a ‘simple’ address information. A routing key may be specified for each kind of destination and source address, e.g., an application server could handle all the SS7 messages containing a core address with predefined digits.
The signaling gateway is in charge of distributing the data traffic from the SS7 network to the IP network and vice versa. A peer might want to send data traffic to an application server. The peer therefore specifies in the routing key employed for routing the data traffic to the application server the point code (PC) and the subsystem number (SSN) of the application server as well as other criteria of the application server. In order to send the data traffic by use of the PC and SSN to the application server, the peer must be aware of the application status of the application server. The signaling gateway is however currently not able to forward the status of an application server to a peer located in the SS7 network or in the IP network.
Further, an application service can be implemented by a plurality of application servers on the IP-network, wherein all application servers associated with the application service share the same point code and subsystem number. Some of the application servers of the plurality of the application servers might be available, while others might be unavailable or congested. As some of the application servers are available, the application service is available. However, there is currently no satisfying solution for signaling the availability or unavailability of an application service being associated with available as well as unavailable or congested application servers to a requesting peer.